Designing a USABLE Application: User Interfaces and Usability Testing

The increased availability of graphical user interface (GUI) tools for application development calls for techniques to ensure that the applications are USABLE, and not just pretty or fancy. GUI tools. such as those available in SASI!I application development using SAS/FSp· and SAS/AF" software with FRAME, .have been created to develop better user interfaces for applications. This paper presents techniques and principles to aid the application developer in designing a usable interface. What Is an Interface? aT 0 the users, the interlace is the system" [Hix & Hartson 1993]. An interface is a means by which a person interacts with something to perform a desired function. We encounter such interfaces repeatedly in our day-ta-day lives. For example, your telephone, your televi$ion remote control, your car stereo controls, your keyboard, and the buttons in an elevator are all interlaces that you encounter daily. Interlaces are evolutionary beasts, where survival of the fittest reigns. Remember the rotary telephone? What was once commonplace is now almost outdated due to a faster, easier-to-use interface: the push button telephone. With this in mind, it seems that manufacturers would be quite concerned with the interfaces of their products. Unfortunately, this is not always the case. After all, how many of us have trouble programming our Own VCRs? Here are some recently encountered examples of some poorly designed interfaces: • A remote control for a popular brand of teleVision has just six buttons: one for power, one for a display to show time and channel, and four buttons in a north, south, east, and west configuration (see Figure 1). These four were likely for volume up/down or channel up/down, but which was which? I changed channels several times instead of changing volume levels! After inspecting the remote control, I found that the north and south buttons were for channel up and down respectively, while the west and east buttons were used to decrease and increase the volume levels. What does 'volume left (or west)' mean? Is that a balance control for a stereo teleVision? Is this a good design? • A typical conventional oven that consists of one oven on top of the other, with control dials side by side! Why? Does the left dial control the bottom or the top oven? • A particular product in which the return key and the enter key behave quite differently. as described by Donald Norman in his book The Design of Everyday Things (1988). If the wrong key is pressed, the last few minutes of work is lost. When this problem was mentioned to the deSigner, he said that the company's secretaries had been using the system for some time with no complaints. When the secretaries were confronted, they admitted that they frequently lost work, but because it was their error, they blamed themselves! Who is really at fault? Is it really user error, or a poor design? 126 Figure 1. Television Remote Control Why Are Products Not Usable? Can you think of some poor designs that you have encountered? Why are these deSigns not usable? Jeffrey Rubin (1994) claims the following five reasons for hard-to-use products and systems: 1. The emphasis and focus while developing systems has been on the system and its functionality, not on the actual users 01 the system. He explains that -there has been an underlying assumption that since humans are so inherently flexible and adaptable, it is easier to let them adapt themselves to the machine, rather than vice versa." In the past, systems were purchased for their functionality, not their usability. A usable system makes sure that users can find and use those functions that meet their needs. The following example from Dumas and Redish (1993) illustrates this point well. In a diSCUSSion at a business meeting, people were complaining that their wordprocessing software did not do envelopes, but in reality, their word-processing software did indeed have that functionality. The users either did not know it, or thought it would be too difficult to learn. In Short, ftBuilding functionality into a product doesn't guarantee that people will be able to use it. ~ 2. The typical user base has changed. In the past, designers were developing products for end users much like themselves. Today. this trend is far from the norm. Current users might range from SCientists with extensive experience in their subject, to computer operators with years of computer experience, to an artist who may be a first-time user. 3. Organizations have treated user-interlace development as common sense. ·Usability is an elusively maddening concepe [Rubin 1994] about which everyone has an opinion. It is obvious that there is no one perfect interface for a given system. If you were to ask several users what was the most important characteristic in a usable interlace, their answers would all be different. 4. Organizations employ separate teams for system development and fail to integrate them together. Often, separate teams will design separate components; teamwork is quite limited. Lack of teamwork often leads to an inconsistent feel, instead of one integrated product. It is essentialfor the individual components of a system to work well together for usability. 5. Developers are NOT users! The computer-knowledge level of a developer is much different than that of typical user. Take, for example, the Institute's vertical product SAS/PH-Clinica~ Software. The application developers of this product do not completely have the knowledge and skills of the physicians, clinical data analysts, and statisticians that use the software every day. It is crucial that developers involve real users in the design of the product if they are to meet their needs. The developers of SAS/PH-Clinical were concerned about what real users did, so they recruited people from the pharmaceutical industry with varying experience levels and performed usability tests with these people. Each developer of SAS/PH-Clinical got to actually see and hear a typical user perform several real life tasks on the product. According to Uncia Lunney, a developer of the product, Gvaluable information about the interface and the software was obtained.· This type of study helps bridge the tremendous gap between users and developers, and thus helps SAS.fPH-Clinical become a more usable product. The employers of the usability subjects actually volunteered their employees for the test. Users want the product to be usable, and they love to ,_give input! In summary, there are many reasons why many products are not usable. Let's look more closely at what 'usable' means. What Is a Usable System? Usable means "that the people who use the product can do so quickly and easily to accomplish their own tasks· [Dumas & Rubin 1993}. Usable is a subjective term, and a usable system is more than 'user friendly,' Usability is the ability to function as an efficient tool, enabling users to perform their tasks. Jakob Nielsen (1993) breaks usability into five distinct attributes: leamability, efficiency, memorability, errors, and satisfaction: 1. Learnability Leamability of a system describes how easily new users can rapidly start completing their tasks. A highly learnable system allows users to become rapidly productive. All of us now expect rapid learning, whether learning a new tracking system, an email utility, or a VCR. Ukewise, many users are becoming accustomed to not having to pick up a manual to figure out how to begin. Learnability is also fairly easy to measure. By presenting novice users with a task and observing and measuring how long it takes them to complete the task, you can quickly and easily detennine the leamability of a system. 2. Efficiency A system needs to be easy to learn and efficient to use. Once users have learned the system, a high rate of productivity can be achieved. However, a trade-off point often occurs between leamability and efficiency (see Figure 2). Users of a highly learnable interface will become somewhat productive quickly, but they soon will reach a point where their productivity levels off. The user of a harder-to-Iearn, yet highly efficient interface will not initially be as productive, but eventually they will become more productive. A good method to ensure that both the novice and the expert user perform at maximum effiCiency is to have different 'user level settings.' An expert user might not need certain 127 prompts, reminders, and messages that are essential for the novice users. By offering the ability to change user level settings, we accommodate both the expert and novice users. Another popular efficiency method is to include accelerators in the user interface. Accelerators allow a user to perform tasks quickly and easily. Typical accelerators include: Function keys • Activating an object by double clicking on it • Command abbreviations, for example, FSE for the FSEDIT command • Mnemonics on pull-down menus that provide users with a short cut for selecting a function (available via PMENUS on some hosts) • T colbars which make popular functions easily accessible. Figure 2 Learning Curve of a Hypothetical System. (Reprinted with permission from Jakob Nielsen, Copyright 1993 by Academi Press, Inc.) 3. Memorability A system has high memorability if the casual user returns to the system after some period of non-use and does not have to relearn the system. Casual users only use systems periodically. These users have used the system before, so they do not need to relearn the system from scratch. A marketing analyst who runs quarterly sales reports is an example of a casual user. 4. Errors A usable system should have a low error rate. In all systems, user errors are unavoidable, but through good interface deSign, user error frequency can be drastically reduced. You can measure error rates by simply counting the number of errors or undesirable actions made by users while performing a task. When errors do occur, it is essential to provide a means by which the user can recover. If you have been caught in an infinite loop, or have been unexpectedly 'kicked out' of a system without notice or explanation, you may remember the resulting frustration that occurred. Potentially dangerous or unrecoverable actions such as record deletion should give users an opportunity to confirm and provide a way to cancel. Good error messages are also crucial for usability. Four basic rules apply to constructing error messages [Shneiderman 1982]: • Error messages should be phrased clearly. Avoid vague messages such as -Error #3304.· • Error messages should be as precise as possible. For example, do not use ·Employee not fqund,· but ·Employee Jason Thomas was not found in the employee data.· • Error messages should constructively attempt to help the user solve the problem. For example, if the input was not valid, the system could provide a list of valid values to choose from. • Good eITor messages do not blame the user or sound intimidating. Messages such as "USER ERROR,~ or ·UNKNOWN COMMAND" are accusatory. Users do not make errors intentionally, so they do not wish to be